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FTP UNIQUE-NAMED STORE COMMAND 


STATUS OF THIS MEMO 


This RFC proposes an extension to the File Transfer Protocol for the 
ARPA-Internet community, and requests discussion and suggestions for 
improvements. Distribution of this memo is unlimited. 


DISCUSSION 


There are various contexts in which it would be desirable to have an 
FTP command that had the effect of the present STOR but rather than 
requiring the sender to specify a file name instead caused the 
resultant file to have a unique name relative to the current 
directory. This would be useful for all sorts of "pool" directories; 
the directories that serve as queues for printer daemons come 
immediately to mind (so do fax and even cardpunch daemons’ queues), 
although naturally the sort of printer queue that a local command has 
to manage the interface to isn’t what’s meant by "pool" in this 
context. 


If we accept the need for such an FTP extension, and that it should 
not be done with an "X" command because it needs to be relied on 
"everywhere," the interesting question then becomes how to mechanize 
it. Probably the most natural way to do it would be either to adda 
"control argument" of -UNM to the syntax of STOR, now that there are 
enough UNIXtm’s around so that this good old Multics trick isn’t 
alien any more, or even to declare that STOR with no argument should 
cause a directory-unique name to be generated. However, either of 
these would necessitate "reopening" the STOR command code, which is a 
distasteful sort of exercise. Since most FTP’s presumably do a 
dispatch sort of thing off a list of command names to begin with, 
then, an additional command would seem to be the way to go. 


Naming the command calls for a bit of thought. STore Uniquely Named 
(-> STUN) is silly; UNIQue comes to close to free advertising or even 
trademark infringement (and confuses fingers if you’re typing); Store 
Uniquely NaMed (-> SUNM) doesn’t avoid free advertising either; 
Uniquely Named STore (-> UNST) might look like a synonym for DELEte, 
though it’s not all that bad; SToRe Uniquely named (-> STRU) is 
taken; and so it goes. The best bet seems to be STOU. 


Of somewhat more practical import, there’s also the question of 
whether the sender needs to be apprised of what the unique name 
turned out to be. Intuitively, sometimes this would be the case and 
sometimes it wouldn’t. Making it optional is almost certainly too 
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much like work, though--even if it does have the subtle virtue of 
finally getting control arguments into FTP. Therefore, why not just 
include it in a suitable response-code’s free text field (unless, of 


course, an avalanche of comments comes in urging it not be done at 
all)? 


Note, by the way, that the intent here is emphatically not to 
sidestep whatever access control, authentication, and accounting 
mechanisms Hosts might have in play before the user can do an old 
STOR or a new STOU, but with suitable publicized ID’s and passwords 
it could be almost as good as the proposal made in RFC 505. 


RECOMMENDATION 


Add a new command, STOU, to FTP, which behaves like STOR except that 
the resultant file is to be created in the current directory under a 
name unique to that directory. The 250 Transfer Started response 
should include the name generated (unless the copy of FTP I have is 
so old that 250 isn’t the right number any more). 
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